Fix the stream sending reliability #222
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #222 +/- ##
==========================================
+ Coverage 24.97% 25.08% +0.11%
==========================================
Files 16 16
Lines 2651 2719 +68
==========================================
+ Hits 662 682 +20
- Misses 1989 2037 +48 ☔ View full report in Codecov by Sentry. |
|
Is this something that where check could be added in https://github.com/containerd/ttrpc-rust/blob/master/example/async-client.rs? Similar to what was done in ttrpc-rust/example/async-stream-server.rs Lines 138 to 139 in 6f12d9c |
|
looks like ci is failing with #219 |
Currently the send() method of stream implemented by send the value to an unbounded channel, so even the connection is closed for a long time, the send function still return succeed. This commit adds a channel to the message so that we can wait until the message is truely written to the connection. Signed-off-by: Abel Feng <[email protected]>
abel-von
force-pushed
the
fix-reliability
branch
2 times, most recently
from
c7fdd33 to
3355f7d
Compare
I think it is hard to write test here because it is some exceptional cases, for example server side restart. or we can do it by disconnecting the underlying connection, but it seems we have no way to do it in client directly. |
I think it is now fixed. |
|
This would make |
|
I think maybe it is the best if ttrpc-rust behaves the same with https://github.com/containerd/ttrpc. The I think maybe we can not say this is "synchronized" as we don't really waiting for a acknowledgement from the other endpoint. we just make sure that the data is written into the connection. |
|
@wllenyj @jsturtevant Could you please take a look at these PRs? |
cherry-pick containerd#220 containerd#222 containerd#220 from containerd/ttrpc-rust
Currently the send() method of stream implemented by send the value to an unbounded channel, so even the connection is closed for a long time, the send function still return succeed.
In this PR I add a channel to the message so that we can wait until the message is truely written to the connection.